2-4 情景二：上班第一天，如何了解团队版本控制流程
入职第一天的 Git 准备
新加入一个团队时，了解团队的版本控制流程是首要任务。以下是入职第一天需要做的 Git 相关准备。
1. 配置本地 Git 环境
# 配置用户名和邮箱（使用公司邮箱）
git config --global user.name "Your Name"
git config --global user.email "your.name@company.com"
# 配置默认分支名为 main
git config --global init.defaultBranch main
# 配置换行符处理（Windows 用户）
git config --global core.autocrlf true
bash
2. 获取项目代码
向组长或同事获取以下信息：
- 代码仓库地址（通常是 GitLab/GitHub/Gitee 的 URL）
- 使用 SSH 还是 HTTPS
- 项目使用的分支策略（Git Flow / GitHub Flow / trunk-based）
- 是否需要 VPN 访问
# 克隆项目
git clone git@gitlab.company.com:team/project.git
# 进入项目目录
cd project
# 查看所有分支
git branch -a
# 查看远程仓库信息
git remote -v
bash
3. 了解团队分支策略
常见的分支策略：
| 策略 | 分支模型 | 适用场景 |
|---|---|---|
| Git Flow | main/develop/feature/release/hotfix | 有计划发布周期的项目 |
| GitHub Flow | main + feature 分支 | 持续部署的项目 |
| Trunk-Based | 只用 main + 短命 feature 分支 | 高频发布的团队 |
4. 创建自己的功能分支
# 从最新的 main 创建功能分支
git checkout main
git pull origin main
git checkout -b feature/your-name/your-task
# 开发完成后推送
git push -u origin feature/your-name/your-task
bash
5. 提交代码的流程
# 1. 编写代码
# 2. 查看变更
git status
git diff
# 3. 暂存变更
git add .
# 4. 提交（遵循团队的 commit 规范）
git commit -m "feat: 添加用户登录功能"
# 5. 推送到远程
git push
# 6. 在 GitLab/GitHub 上创建 Merge Request / Pull Request
bash
6. Commit 规范
大多数团队使用 Conventional Commits 规范：
<type>(<scope>): <subject>
type:
feat 新功能
fix 修复 bug
docs 文档变更
style 代码格式（不影响逻辑）
refactor 重构
test 测试
chore 构建/工具变更
text
常见问题
| 问题 | 解决方案 |
|---|---|
| 无法克隆仓库 | 检查 SSH 密钥是否配置、是否有权限 |
| 不知道在哪个分支开发 | 问组长，或查看团队的 CONTRIBUTING.md |
| commit 被拒绝 | 可能是 pre-commit hook 未通过（如 ESLint 检查失败） |
| 不知道如何命名分支 | 遵循团队约定，通常为 feature/姓名/功能描述 |
参考资源
- Conventional Commits - Commit 规范
- Git Flow 工作流
↑